經過 51 個日出日落
連續的 30 個日子，我們終於來到最後一天。

回頭看看 my-refrigerator，從一開始只有一個想法： 「我喜歡下廚，但常常不知道冰箱裡還有什麼。」

到現在，已經逐漸完成一個真正可以使用的生活工具。

我們不只是使用 Claude Code 寫程式，更重要的是學會如何讓 AI 參與整個軟體開發流程。

從建立 Vue 專案、設計資料庫，到建立冰箱與採買功能，再到 AI 食材辨識、全聯特價食材、AI 食譜推薦，最後加入 Test、Debug、Refactoring、MCP、Hooks 與 CI/CD。

而今天，我們要做的不是再新增一個功能，而是把這 30 天累積下來的 Skill 與開發方法整理起來。

30 天到底建立了哪些 Skill？

這次 my-refrigerator 最重要的成果之一，就是我們逐漸建立了一套屬於專案自己的 Skill。

Frontend Skill
Database Skill
Backend/Data Skill
Feature Skill
AI Vision Skill
Data Skill
AI Recommendation Skill
Testing Skill
Automation Skill

每一個 Skill 都負責不同的事情。

這些 Skill 加在一起，就不再只是零散的 Prompt。

它們開始形成一套：

「AI 應該如何參與這個專案開發」的規則。

從「叫 AI 寫程式」到 AI Native

這 30 天最大的改變，其實不是學會多少 Claude Code 指令。

真正的改變是：

我們開始改變寫程式的方式。

以前可能會對 AI 說：

「幫我寫一個登入功能。」

現在則 AI 不再只是「寫程式的工具」，而是開始參與整個 Software Development Lifecycle。

(碎念一句：雖然對於開發還是滿懷著熱血，但是時代總是在進步的...)

my-refrigerator 的完整流程

經過 30 天之後，my-refrigerator 也形成了一個完整的使用情境。

📷 拍照
 ↓
AI 辨識食材
 ↓
🥬 我的冰箱
 ↓
發現缺少食材
 ↓
🛒 採買清單
 ↓
查看特價食材
 ↓
🛍️ 完成採買
 ↓
🥬 更新冰箱
 ↓
🤖 AI 食譜推薦
 ↓
🍳 開始料理

這也是為什麼我會選擇「冰箱」作為這 30 天的實戰專案，是一個真的來自生活需求的產品。

結語

這 30 天，我們從：「我想做一個 智慧冰箱。」

一路走到：「我可以和 AI 一起打造一個完整的智慧冰箱。」

這中間最大的變化，不是 AI 變得多厲害，而是我們開始學會：

如何讓 AI 成為自己的開發夥伴，這 30 天練功終於結束！

不過，真正的 AI Native 開發，還正在路上而已……

最後，放上更新緩慢的 my-refrigerator 連結，為了省一點 token 費用，沒有做註冊功能，歡迎有能力自行接 supabase和願意花個5美元接 Claude API 的大家可以去嚐鮮AI 食材辨識功能，很新奇！

謝謝這次鐵人賽，讓我更深入認識了 Anthropic 所打造的 Claude Platform 小天地，以及屬於新時代開發者的 Claude Code CLI。

✦ ── 文末補充區

號外號外，Claude 普發了 Reset 卷 與 Cloud Session Credit $100 元，大家快去領！

可以到 Claude Code ，登入後在頁面左下角點擊自己的帳號，至 Settings > Usage 頁面，就可以看到如下圖的畫面了～～

以下整理 AI Native 開發的心得與反思，作為日後提醒自己（誤）時服用。

有了AI夥伴的心得

「程式碼是誠實的，少一個分號、型別不對，它就是報錯給你看，你總有辦法 trace 到 root cause。」
雖然AI的出現，讓除錯變得容易許多。
但是AI卻無法通靈人們的想法與實際需求，這讓開發系統除了程式碼邏輯以外，表達能力也顯得重要。
以前總是花很多時間 coding，現在重要得反而是釐清需求，
一樣都在敲鍵盤，只是從程式碼變成了文字對話。

「隨著 AI 技術的大幅進度，了解系統架構（System Architecture）系統架構變得十分重要。」
現在的 AI 能夠快速生成程式碼、補齊語法細節，開發者的角色從「寫程式的人」轉變為「設計系統的人」。
而系統未來要承載多少流量、需要考慮什麼樣的擴充性，
以及商業邏輯與取捨（trade-off）是什麼？
這些都是屬於「架構層級」的判斷，「為什麼這樣設計（Why）」與「要解決什麼問題（What）」仍然得靠人來釐清。

這也是為什麼溝通與表達能力，在 AI 協作時代反而變得更加關鍵：需求要說得夠精確，並且要有能力拆解問題。
所以與其說 AI 取代了 CODING，不如說它把開發者的角色往「更上游」的位置推了一步，從實作細節，移動到系統思考與需求釐清。而這也意味著，未來重要的地方，是把問題想得更透徹、將需求講得更清楚。

追求技術精進的反思

「軟體工程是條終身學習的漫漫長路，技術迭代快得讓人窒息。」
在追求流行技術與改動既有穩定系統，很容易遇到兩難的情境。
在評估新技術時，得要理性分析它能帶來什麼效益？足以優化多少效能？會花費多少成本？會需要多少時間？
又會引入什麼外加風險？或是怎麼做才算是符合時宜的測試？
在這些問題妥善評估以前，盲目求新求快，反而會讓自己陷入異次元時空泥淖裡頭。

「成本與品質不再是單選題，而是需要持續的權衡藝術。」
科技日新月異，我們往往都會追求技術精進。
但是回頭看，要有一個成熟的資訊工程判斷，就得建立在反覆檢視之上：
新技術解決的是真實存在的痛點，還是因為它看起來比較新潮呢？
串接了新的服務，既有程式碼的相容性如何？文件與監控工具的重建是否需要花費大量額外的成本？

而使用新技術往往伴隨著未知的邊緣案例（edge case），是否已評估好新的風險？執行足夠的覆蓋率測試？
在發佈更新的時機是否合理？會不會反而影響系統的穩定性？有沒有真正的需求對齊？
這些都是值得去我們去仔細思考、反覆琢磨後，才能做出對系統最好的選擇。

但這也不代表我們要一直原地踏步。兩難從來不是「要不要變」，而是「何時變、如何變、能承擔多少代價」，必須要持續地權衡，誠實地去試問「這麼做，真的是為了系統好嗎？」，才能逐漸沉澱出好的決定。